我用 M3 跑了三个真实长程任务，发现它强在后半程
我用 M3 跑了三个真实长程任务，发现它强在后半程
来源：htmlDecode("AI产品黄叔")
原文链接：https://mp.weixin.qq.com/s/EoG7kiKveinPxSabY57dKA
最近这几天，大家都在测 MiniMax M3。
有人测登录页复刻，有人测视频理解，有人测网页游戏，也有人测截图写代码。都挺好，但我总觉得还差一点。
因为 M3 真正要看的，不是单点 Demo 上限，而是长任务后半程的稳定性。
真正麻烦的不是“给我写一个页面”。真正麻烦的是： 你有旧代码、旧文档、自己的知识库、改了一半的需求，还希望模型不是给你表演，而是真的接住一个复杂项目。
所以这次我没有只测小 Demo。我直接拿 M3 跑了三个真实任务：
第一个，把 zaoxiaban.top 从“AI 编程课程营销页”，改造成一个 Agent Native 官网。
第二个，搭一个“黄叔写作专家团”，让它读取我的知识库、历史文章、风格指南和个人经历，稳定产出公众号母稿。
第三个，把一份飞书知识库做成可玩的“知识库探案室”，让它从长文档里抽结构、设计关卡，再落成网页产品。
跑完之后，我最大的体感不是“M3 会写代码”，而是任务越拖长、上下文越乱，它越能把前面的信息和后面的动作接起来。
01 先说 M3 的更新
这次 M3 的更新，我觉得不能只看参数，当然参数本身也很关键：
1M 上下文、原生多模态、Coding 和 Agentic 能力，表面上是三个模型能力点。但放到 Agent 时代，它们其实对应的是一个 Agent 大脑最关键的三件事。
第一，能记住现场。
长程任务不是单轮问答。它会经历读需求、读资料、读代码、写方案、改文件、跑构建、看报错、再修正。1M 上下文的意义，不是“能塞更多字”，而是让模型在任务后半程还保留完整工作现场。
第二，能看懂现场。
真实任务里的输入不只是文字。旧官网截图、页面结构、文档图片、代码文件、工具反馈，都可能同时出现。原生多模态的价值，是让模型不只听你描述，而是能直接理解任务环境。
第三，能推动现场。
Coding 和 Agentic 能力决定了模型能不能把理解转成行动：拆任务、写代码、调工具、读错误、继续修。很多模型能给建议，但真实工作流需要它把事情往前推。
所以 MiniMax Code 只是入口，M3 才是背后的大脑：
我这次真正想看的，不是 MiniMax Code 的交互形态有多顺手，也不是 M3 会不会调用工具，而是这三个模型能力合在一起之后，能不能撑住一个真实长程任务。
弱一点的模型，也能把任务开个好头。但任务一长，就容易忘约束、重复犯错、改偏方向、修一个地方坏另一个地方，最后变成“看起来一直在忙，其实已经散了”。
我想看的只有一件事：
M3 能不能把一个长任务，从开头一路带到结尾。
后面的三个 Case，都是围绕这件事展开。
02 第一个真活：2 小时，把营销页改成 Agent Native 官网
第一个任务，是改 zaoxiaban.top。
这个网站原来是我的 AI 编程课程官网。但最近课程方向变了，从“AI 编程社团”，转向“Agent 从小白到高手”。官网如果还停在之前的版本里，就会很尴尬：嘴上说 Agent，身体还是传统营销页。
我给 M3 的任务，不是“帮我做一个漂亮页面”。而是让它先诊断旧官网，再重构信息架构，最后直接改代码。
这个 Case 的关键，不是纯文本改代码。它第一步是先“看懂”旧官网：页面有多少 section，视觉层级是什么，互动入口在哪里，哪些核心叙事没有被打出来。
后面它能判断“PRD 写 8 个 section，但实际页面有 11 个”，本质上就是先用多模态理解了现有页面结构。
它随后拉起 4 个 Agent 并行做调研和改造。
最后落地的改造包括： 维度 改造前 改造后 页面结构 11 个 section 8 个 section 课程叙事 4 个 Part 4 阶段 Agent 成长路径 互动元素 1 个课程大纲展开 AI 输入框、阶段切换、试 Agent 演示 视觉风格 亮色科技蓝 SaaS 感 暗色、节点网络、等宽字体 核心叙事 很多武器缺席 搬上 Agent First 主线
最后它直接改了代码：14 个文件，大约 2000 行 TypeScript/TSX，3 个 JSON 数据重写，5 个新组件，6 个静态页预渲染。dev server 2.3 秒启动，首次渲染 3.3 秒，HTTP 200。
整个前端页面的样式还是挺不错的，并且它特别聪明的做了一个Agent演示。
这个 Case 的结论不是“M3 会写前端”。
更准确地说，是： M3 能先看懂一个真实产品的当前状态，再把它转成工程改造方案。
看懂页面，是多模态；重构叙事，是产品判断；最后改代码，是 Coding。三件事连起来，才是 Agentic Coding。
它不是只生成一个页面，而是在旧项目语境里连续完成“理解现状 - 提出方案 - 修改代码 - 验证结果”。真正有价值的是，这条链没有在后半程断掉。
03 第二个真活：用 M3 搭自己的写作专家团
第二个任务更贴近我的业务。
黄叔也是得到AI学习圈的特聘导师，最近购买了得到的新产品：“得到大脑写作专家团”，感觉还不错。
我马上想到一个问题：我自己的知识库里，本来就有大量历史文章、风格指南、核心概念、选题卡、思考记录和 Skill。那为什么不能搭一个更像我的写作专家团？
我给 M3 的目标不是写一篇文章，而是搭一个系统。
它先盘点我本地已有素材：核心概念词典、文风指南、00-我 里的 MBTI、盖洛普、价值观、思考模式、爆款文稿库、已发布选题。然后给出专家团方案，并生成 Agent Team。
它还自己构建了反馈学习环。也就是说，这不是一次性写稿，而是一个会读素材、分角色、跑多轮反馈的写作系统。
我用它跑了 3 个 cycle： Cycle 选题 耗时 风格一致性 1 别把 AI 当电子奶嘴 25 分钟 87.5% 2 AI 不是答案机 22 分钟 100% 3 M3 三个月真实体验 24 分钟 100%
这里最有意思的是风格画像的变化：Cycle 1 学到的口语化情绪表达，Cycle 2 自然复用；Cycle 1 缺的转折句式，Cycle 3 补回来。不是套模板，是在反向编译风格模式。
但这个 Case 里，最让我舒服的不是风格学习，而是 角色边界没乱 。
什么时候是风格官，什么时候是主笔官，什么时候是参谋官，它没有明显串台。
多 Agent 协作最怕的不是某个角色不够聪明，而是角色边界乱掉：调研官开始写作，主笔官开始假装审稿，参谋官开始替你圆场。一乱，整个系统就废了。
第一个 Case 证明的是 M3 能接工程：读旧代码、改文件、跑 build。
第二个 Case 更深一层，证明的是 M3 能在一长串上下文里保持角色边界、记住前面发生了什么，并把多轮反馈带到后面的输出里。
这个 Case 看的是 M3 的长程约束保持能力。多角色、多轮反馈、风格画像、审核标准同时存在时，它还能维持角色边界和写作方向，这比单次生成一篇文章更能暴露模型能力。
04 第三个真活：把飞书知识库做成可玩的探案室
第三个任务，我给 M3 的不是代码库，也不是文章选题，而是一份飞书知识库。
里面是社团资料、学习路径、工具清单、直播回放、活动索引。正常模型看到这种东西，大概率会给你总结成目录，最多再生成一份 FAQ。
这次我没有让它总结。
我让它把这份知识库改造成一个可以玩的网页探案室。这个知识库有几十个章节，加起来几十万字。
结果它先把文档拆成 5 个房间：入门大厅、工具陈列室、双线选择器、直播回放室、终极核心。每个房间都有线索、问题、答案校验、错误提示和通关复盘。
这里最有意思的不是它写了多少代码，而是它真的理解了资料库的结构：哪些内容适合做线索，哪些信息适合做谜题，最后玩家通关后应该理解哪一句核心判断。
比如“入门大厅”考的是新人最该先看的入口；“双线选择器”考的是路径 A 和路径 B 的差异；“直播回放室”要求从一堆时间线里找出 8 月 1 日直播的三个要点。玩家答对以后，它还会展示答案依据来自文档哪里。
总结是把资料压扁。这个任务是把资料重新组织成一个交互产品。
它要先读长文档，再抽结构，再设计关卡，再把内容落成数据结构，最后写成一个可运行的 Next.js 网页。项目里还有 localStorage 进度保存、递进提示、通关复盘和演示模式。最后 build 通过。
这个 Case 看的是 M3 的信息重构能力：它不是把飞书知识库总结成摘要，而是先抽取章节结构和关键线索，再把资料重组为房间、谜题、状态机和前端页面。
官网改造，是它接工程。写作专家团，是它撑长程。知识库探案室，是它把长上下文产品化。
这三个合在一起，才是我这次对 M3 的真实感受：它不是在一个点上表演，而是在一串任务里往前推进。
05 为什么 1M 上下文不是炫技
讲到这里，就能回到 M3 这次最重要的技术点：1M 上下文。
很多人看到长上下文，第一反应是：那我是不是可以塞一本书进去？当然可以。但这不是我最关心的用法。
我真正关心的是： Agent 在长任务里能不能不失忆。
真实开发任务会经历：读需求、读旧代码、读文档、生成方案、写代码、跑 build、看到报错、回头修、再跑、再根据用户反馈改。
如果上下文撑不住，就会出现一种很烦人的状态：前面刚说过的约束，后面忘了；刚修过的 bug，又用同样方法再修一遍；刚定好的风格，写到后面变味了。
这不是智商问题，是记忆问题。
MiniMax 这次的 MSA 机制，简单说就是让模型在长上下文里把注意力用在刀刃上。官方数据是，在 100 万上下文长度下，每 token 计算量只有上一代的约 1/20，prefilling 阶段加速约 9.7 倍，decoding 阶段约 15.6 倍。
你不需要记住这些技术细节。你只要记住一句话： 长上下文不是为了装更多资料，而是为了让模型在持续干活时不那么容易失忆。
这也是三个 Case 里最直观的体感。官网改造需要它记住旧页面、代码结构、知识库概念和新方案；写作专家团需要
它记住我的风格画像、个人经历、核心概念和前几个 cycle 的反馈；知识库探案室需要它记住飞书资料库的章节结构、线索来源、谜题答案和前端状态机。
如果上下文不稳，这些任务都会变成：前半段还像人干的，后半段开始像临时工接班。
所以 1M 上下文真正支撑的，是让模型在长程任务后半段还保留完整工作现场。
06 边界：它强在哪，也该知道哪不该吹
说到这里，容易写成一篇夸夸稿。但我不想这么写。
这几个案例也暴露了 M3，或者说当前 Agent 工作流的几个边界。
第一个边界：长程稳定，不等于全程自治。
M3 能把任务往前推很多步，但当工具卡死、方向需要取舍、质量需要判断时，人仍然要介入。
第二个边界：模型更稳，不等于输出天然可信。
尤其是写作、数据、引用、知识库重组这类任务，模型越能把内容组织得像真的，人越要检查证据链。
第三个边界：能做成产品，不等于完全理解业务。
知识库探案室能跑起来，但哪些线索来自原文，哪些是模型重组，哪些是为了体验做的简化，都需要人守最后一道质量门。
这三个边界合在一起，其实指向同一个判断： M3 更适合长程任务，但它不是责任主体。
它能把任务往前推很多步，但最后的方向、事实、审美和业务取舍，还是要有人守门。
07 Token 就是电：长程任务必须敢用
最后补一个很多人会忽略，但我觉得很关键的点。
如果你只是偶尔问模型几句话，价格差异不明显。但如果你开始用 Agent 跑真实任务，情况完全不一样。
官网改造会读代码、读文档、写方案、改文件、跑构建、修错误；写作专家团会读历史文章、读知识库、跑多角色审核；知识库探案室则要把一份飞书资料库读完、拆结构、做关卡、写前端、跑 build。这些都很吃 token。
我之前一直有个类比： Token 就是电。没有电，所有 Agent 都只是摆设。
你一旦开始心疼 token，就会下意识减少尝试次数。少跑一轮调研，少跑一次 verifier，少让 Agent 多读几个文件，少让它再改一版。最后看起来省了 token，其实是在省 Agent 的脑子。
所以这次 MiniMax 的 Token Plan，我关心的不是“便宜”这一个点，而是它能不能让用户敢用。套餐数字截图里都有，但具体权益、周限额和可用额度，还是以每个人控制台显示为准。
这里要说清楚一点：Token Plan 这次本身也在升级，从过去更偏订阅额度的理解，切到更行业通用的 Token-Based 计量。这个变化对长程 Agent 是合理的，因为 M3 更大、更智能、有原生多模态和 1M 上下文，本来就会吃更多算力。
我自己这轮测试，前后跑了 2-3 个小时，包括官网改造、专家团和知识库探案室，在 5 小时/周额度里并没有把额度打穿。不过我的账号有历史权益，下面这张图只能说明这轮任务的实际消耗感受，不能直接代表所有新购账号。
官方这次也给了几类过渡补贴：
2026 年 3 月 22 日前购买、原本没有周限额的老用户，M2.7 和 M3 都继续保持无周限额。
2026 年 3 月 22 日到 2026 年 6 月 5 日上午 10 点前购买 Token Plan 的用户，在有效订阅周期内，M3 周限额会永久加赠 50%。
M3 上线后的前 7 天，也就是 2026 年 6 月 1 日到 6 月 7 日，所有订阅用户的 5 小时/周使用额度会翻倍。
建议大家感兴趣的可以赶紧去购买一下Token Plan，享受最新的福利。
08 结论
所以我最后的判断是： M3 这次真正拉开的，不是 Demo 上限，而是长程任务的下限。
以前很多模型也能写页面、写文章、写一段代码。但任务一变长，开始涉及旧项目、飞书知识库、本地文件、工具反馈、反复修改，差距就出来了。
弱一点的模型，前几步也能跑得挺漂亮。但跑到后面，容易忘约束、改错方向、重复犯错，最后变成“看起来一直在忙，其实没往前走”。
M3 这次让我看到的，是它更能把一串事接起来：读资料、拆任务、做方案、改代码、跑验证、吃反馈，再继续往前推。
别只测 Demo。给它一条完整任务链。
能把这条链跑顺，才是 Agent 模型。跑不顺，再漂亮的 Demo 都只是样片。